This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 55e1e8b:

It looks like this would break compatibility with Expo Go, at least for now. What is your estimation on how breaking this change is?

Would my workaround be sufficient for us to not ship a breaking change? #3583 (comment)

@CodyJasonBennett That would still be a breaking change as well, since expo-file-system/legacy was only introduced in Expo 54. Before that the old API lived under expo-file-system and the new API was under expo-file-system/next. But it would be compatible with the latest Expo Go

@krispya I chose this approach because it felt more future-proof. Personally, I don’t see development builds as a blocker for adopting a library (more details here: https://github.com/expo/fyi/blob/main/expo-go-usage.md), especially since the underlying issue has already been fixed upstream and just needs to ship in the next Expo Go release. That said, I’m happy to hold off if you’d prefer to wait until the fixed Expo Go version is available

Why would it be a breaking change? Does it not work? The whole point is to conditionally import, which allows us to support either subpath or either version. My hope is that it could be a quick fix we can ship until we drop the legacy API in the next major.

Sorry, I misread your suggestion and didn't realize it was a conditional import rather than a direct change. I haven't tested this approach yet, but I assume it should work

@CodyJasonBennett I tested your suggestion, but encountered an error requiring expo-file-system/legacy on Expo 53. I switched to using try/catch, and it worked on both Expo 53 and 54. You can check it out here: #3599